代码管理及工作流

代码管理方法

项目代码托管在公司内部部署的 gitlab 服务上，采用前后端分离的思想，项目名分别是：

1. 前端：frontend

2. 后端：backend

代码提交格式规范

git commit message 的写法遵循以下格式，例如：

git commit -m 'refs #PROJECT_ID-123 what I just have done'

我们已经在前后端项目中内置了 git hook，以保证不按照这个格式提交不成功。

包管理工具

包管理我们目前统一使用 Yarn，日常增减包依赖时需要同时更新 yarn.lock，保证每次 package.json 和 yarn.lock 同步改变（在一次 commit 中）。

工作流

我们采用的是Gitlab flow，相比 Git flow 来说，Gitlab flow 更简单，只要有基本的 Git 技能即可上手，但是需要有 CICD 的支持，需要有多分支分别自动部署的能力，这样在合并到 master 之前代码基本上已经经过很好的测试，基本上不会出太多 bug。

版本迭代

我们的版本号属于内部标识，主要用来区分每次发布的任务范围。迭代周期从以前的不太稳定周期逐渐过渡到每两周迭代一次。采用的是Scrum 敏捷开发方法，并尽可能遵守里面的行为准则。

任务跟踪管理

我们采用 JIRA 管理每次迭代的任务分配，内置了许多基于 Scrum 敏捷开发思想的功能。需要注意的是任务的类型，估时，状态流转，经办人流转。除了正常的迭代工作之外，还需要尽可能理解系统背后的敏捷开发思想，并共同建设我们的自组织团队。

每个 Sprint 包含一个部署相关的任务，例如：3.3 部署相关，在这个任务里包含部署备注，合并冲突修复，以及定期反向合并等事务。

分支命名

根据任务类型的不同，我们的分支有以下几种前缀：

• release/A.B，这是迭代分支，后面是我们每次迭代的版本号。

• hotfix/SMART-ISSUE_ID/DESCRIPTION，这是 hotfix 分支，用于解决线上 bug 或者紧急需求。

• feature/SMART-ISSUE_ID/DESCRIPTION，这是特性分支，较少用到，目前也很少找到必须用特性分支的理由

• document/DESCRIPTION，这个是文档分支，较少用到

所以，我们主要使用上面两种类型的分支命名方式，并且迭代分支在每次迭代之前就需要建好，开发团队只需要掌握并遵守 hotfix 分支的命名规则即可。

比较特别的是 master 作为我们的主分支，部署在 dev 环境，而生产环境使用的分支是 production 分支，master 到 production 分支采用单向 merge request 的方式合并代码。好处是上线过程流畅，操作少，风险小。只有当 master 有新功能代码还无法上线时，production 需要 hotfix 时，才会打破单向合并，但是目前为止还没有发生过这样的情况，即使发生，只要反向合并即可解决。

多环境

我们的开发流程利用 Gitlab 的 CI/CD 特性实现了多环境的自动部署，主要有以下环境：

环境	别名	生命周期	自动创建	自动部署	备注
环境	别名	生命周期	自动创建	自动部署	备注
生产环境	production	一直存在	是	自动编译，一键部署	生产环境基于 Openshift 容器云
生产测试环境	production-test	一直存在	是	自动编译，一键部署	生产测试环境用于查线上 bug
仿真环境	testing	一直存在	是	自动编译，自动部署	目前仿真和生产几乎等同，没有隔离
开发测试环境	dev	一直存在	否	自动编译，自动部署	提测时才会到这个环境
迭代环境	release-*	迭代结束即销毁	前端是，后端否	自动编译，自动部署	测试中，即将实现自动创建
其他环境	feature-*	feature 结束即销毁	前端是，后端是	自动编译，自动部署	根据团队最新约定，hotfix 不建环境

目前团队主要工作在迭代环境，并且在迭代的过程中，始终保持密切配合，同步测试，以达到提测时已经有了不错的质量保证，提测后更多的是进行一定的回归测试和确保代码合并到 master 之后仍然能正常工作。

建议开发工具

虽然当下有许多优秀的开发工具，建议统一使用 vscode 作为主要编辑器，并且按照 editorconfig 以及其他有助于提高工作效率和质量的插件。